前端项目如何管理

前端项目的管理分为两个维度：项目内的管理与多项目之间的管理。

1. 项目内的管理

在一个项目内，当有多个开发者一起协作开发时，或者功能越来越多、项目越来越庞大时，保证项目井然有序的进行是相当重要的。

一般会从下面几点来考证一个项目是否管理得很好：

可扩展性：能够很方便、清晰的扩展一个页面、组件、模块
组件化：多个页面之间共用的大块代码可以独立成组件，多个页面、组件之间共用的小块代码可以独立成公共模块
可阅读性：阅读性良好（包括目录文件结构、代码结构），能够很快捷的找到某个页面、组件的文件，也能快捷的看出项目有哪些页面、组件
可移植性：能够轻松的对项目架构进行升级，或移植某些页面、组件、模块到其他项目
可重构性：对某个页面、组件、模块进行重构时，能够保证在重构之后功能不会改变、不会产生新 bug
开发友好：开发者在开发某一个功能时，能够有比较好的体验（不好的体验比如：多个文件相隔很远）
协作性：多人协作时，很少产生代码冲突、文件覆盖等问题
可交接性：当有人要离开项目时，交接给其他人是很方便的

1.1 可扩展性

对于前端项目而言，可扩展性是并不难的，因为很多时候前端的代码、文件分块都是按照页面来的，所以天然就是一块一块的。

但这里还是要提一下，因为有些开发者不喜欢分块，把应该分块的东西杂揉在一起，比如：

- src/
  - main/                    # main 目录
    - css/                   # css 集合
      - alpha.css
      - beta.css
      - ...
    - js/                    # js 集合
      - alpha.js
      - beta.js
      - ...    
    - alpha.html             # alpha 页面
    - beta.html              # beta 页面
    - ...

更好的方式：

- src/
  - main/                    # main 目录
    - alpha/                 # alpha 页面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 页面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

使前端项目具有高可扩展性，一般从目录文件结构入手，可以参考：目录结构优化。

1.2 组件化

这里的组件化是项目内的组件化，我们可以把多个页面之间共用的大块代码独立成组件，多个页面、组件之间共用的小块代码独立成公共模块。

这样做的目的是为了提高代码的可重用性，避免重复造轮子。另外，也有利于代码之间的解耦。

比如：

- src/
  - data/                    # 常量、静态数据目录
    - data1.js          
    - data2.js
    - ...          
  - components/              # 组件目录
    - componnet1/          
    - componnet2/
    - ...          
  - utils/                   # 工具函数目录
    - util1.js          
    - util2.js
    - ...     
  - ...

可以参考：组件化。

1.3 可阅读性

这里的可阅读性有两个方面：目录文件结构、代码结构。

1.3.1 目录文件结构

目录文件结构可阅读性的好与否除了跟开发者有关系外，跟项目的搭建者也有很大的关系，因为如果搭建者在最初就定义好整个项目的目录结构，对后期的开发者是一个很好的约束。

可阅读性比较差的目录文件结构：

- src/
  - css/                     # css 集合
    - main/                  # main 目录
      - alpha.css
      - beta.css
      - ...
  - js/                      # js 集合
    - main/                  # main 目录
      - alpha.js
      - beta.js
      - ...
  - html/                    # html 集合
    - main/                  # main 目录        
      - alpha.html           # alpha 页面
      - beta.html            # beta 页面
      - ...

可阅读性比较好的目录文件结构：

- src/
  - main/                    # main 目录
    - alpha/                 # alpha 页面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 页面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

关于目录文件结构的高可读性，可以参考：目录结构优化。

1.3.2 代码结构

代码结构的可阅读性大部分取决于开发者的水平，但我们可以使用工具帮助开发者书写规范、格式良好的代码。

主要有下面的工具：

.editorconfig: 统一每个开发人员的编辑器配置
eslint: 检查 js 语法（包括 jsx 语法），然后最大程度的矫正不符合规范的代码
stylelint: 检查 css 语法（包括 less, scss 语法），然后最大程度的矫正不符合规范的代码
prettier: 代码格式优化
husky + lint-staged: 强制开发人员对代码进行检查、自动矫正与优化

上面的具体用法可以参考：

1.4 可移植性

可能的情况下，让项目具有一定的伸缩性，可以在未来轻松的对项目进行架构升级。

让项目能够轻松的移植某些页面、组件、模块到其他项目，需要对整个项目代码尽量的解耦与模块化。另外，也与后面会讲到的“项目之间的统一性”有关。

1.5 可重构性

对页面、组件的重构是常有的事，但怎样保证在重构之后功能不会改变、不会产生新 bug，这就得靠测试用例了。

js 模块：jest / mocha / tape / ava
React 组件：enzyme + jest，另外可以使用 react-testing-library 代替 react-dom/test-utils
Vue 组件：vue-test-utils + jest / mocha / tape / ava

可以参考：

1.6 开发友好

这主要是从目录结构优化着手，比如：

像下面这种目录结构，如果要编辑一个页面，需要到处找页面相关的文件，编辑器上就会形成一个很长的目录树，一点不友好：

- src/
  - css/                     # css 集合
    - main/                  # main 目录
      - alpha.css
      - beta.css
      - ...        # 中间有 30 个页面
  - js/                      # js 集合
    - main/                  # main 目录
      - alpha.js
      - beta.js
      - ...        # 中间有 30 个页面
  - html/                    # html 集合
    - main/                  # main 目录        
      - alpha.html           # alpha 页面
      - beta.html            # beta 页面
      - ...        # 中间有 30 个页面

而像下面这种目录结构，所有的文件都在一个目录下，找文件就很方便，而且很清晰：

- src/
  - main/                    # main 目录
    - alpha/                 # alpha 页面
      - index.css            # css 入口文件
      - index.js             # js 入口文件
      - index.html           # html 入口文件
      - ...
    - beta/                  # beta 页面
      - index.css
      - index.js
      - index.html
      - ...
    - ...

1.7 协作性

当项目变大、多人协作时，我们就需要管理好哪些是正在开发的代码、哪些是提交测试的代码、哪些是已经上线的代码、如何避免代码冲突与线上新代码被旧代码覆盖等等。

具体可以参考：web 项目如何进行 git 多人协作开发。

1.8 可交接性

当有人要离开项目时，就需要把他负责的代码交接给别人，但怎么样才能使交接是轻松愉快的？

那就是文档，包括注释文档、接口文档等。想想，如果没有文档，该怎样交接呢？

可以参考：api 接口管理工具。

2. 多项目之间的管理

多个项目之间，如何管理好项目之间联系，比如共用组件、公共模块等，保证快捷高效开发、不重复造轮子，也是很重要的。

一般会从下面几点来考证多个项目之间是否管理得很好：

组件化：多个项目共用的代码应当独立出来，成为一个单独的组件项目
版本化：组件项目与应用项目都应当版本化管理，特别是组件项目的版本应当符合 semver 语义化版本规范
统一性：多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库
文档化：组件项目一定需要相关的文档，应用项目在必要的时候也要形成相应的文档

2.1 组件化

这里的组件化是项目之间的组件化，我们可以把多个项目共用的代码独立出来，成为一个单独的组件项目。

这样做的目的也是为了提高代码的可重用性，避免重复造轮子。另外，也便于版本化管理组件。

- project1/                  # 项目一
  - package.json
  - src/ 
  - ...
  
- project2/                  # 项目二
  - package.json
  - src/ 
  - ...  
  
- component1/                # 组件一
  - package.json
  - src/ 
  - dist/ 
  - ...
  
- component2/                # 组件二
  - package.json
  - src/ 
  - dist/ 
  - ...

在 project1 中使用 component1、component2:

# package.json
{
  "dependencies": {
    "component1": "^0.0.1",
    "component2": "^0.0.1"
  }
}

import component1 from 'component1';
import component2 from 'component2';

常用组件有：

@yourCompany/utils: 工具类
@yourCompany/shortcut.css: 快捷 css 类
@yourCompany/data: 常用静态数据
...

组件化一般会与私有 npm 仓库一起使用。

可以参考：

2.2 版本化

如果应用项目使用 npm 来管理依赖，就是版本化管理了。

组件项目更不用说了，值得提一下的是组件项目的版本号应当符合 semver 语义化版本规范。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，

次版本号：当你做了向下兼容的功能性新增，

修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

可以参考：

2.3 统一性

多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库。

这样做的目的是减少项目之间的环境差异，有利于项目之间的代码移植，也更有利于组件化、代码重用。

可以参考：

2.4 文档化

完善的文档，不管是对组件项目还是应用项目，都是很重要的。

组件项目需要用文档告诉开发者组件怎么用、有哪些接口；应用项目需要用文档来做小组交流、项目交接等。

后续

更多博客，查看 https://github.com/senntyou/blogs

作者：深予之 (@senntyou)

前端项目如何管理